Technical Field
This application relates generally to secure network-based communications using cryptographic protocols.
Brief Description of the Related Art
Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols that provide Internet communication security. They use asymmetric cryptography for authentication and key exchange, symmetric encryption for confidentiality, and message authentication codes for message integrity. TLS/SSL is initialized at a session layer then works at a presentation layer. In particular, first the session layer has a handshake using an asymmetric cipher to establish cipher settings and a shared key for that session. Thereafter, a presentation layer encrypts the rest of the communication using a symmetric cipher and that session key. In both models, TLS and SSL work on behalf of the underlying transport layer, whose segments carry encrypted data. TLS is an IETF standards track protocol, defined in RFC 5246 and RFC 6176.
Distributed computer systems are well-known in the prior art. One such distributed computer system is a “content delivery network” (CDN) or “overlay network” that is operated and managed by a service provider. The service provider typically provides the content delivery service on behalf of third parties (customers) who use the service provider's shared infrastructure. A distributed system of this type typically refers to a collection of autonomous computers linked by a network or networks, together with the software, systems, protocols and techniques designed to facilitate various services, such as content delivery, web application acceleration, or other support of outsourced origin site infrastructure. A CDN service provider typically provides service delivery through digital properties (such as a website), which are provisioned in a customer portal and then deployed to the network. A digital property typically is bound to one or more edge configurations that allow the service provider to account for traffic and bill its customer.
For a traditional RSA-based TLS session, the two sides of a connection agree upon a “pre-master secret” (PMS) which is used to generate the parameters for the remainder of the session. Typically, the two sides use RSA asymmetric encryption to establish the pre-master secret without exchanging the actual value in plaintext. In operation, the SSL client generates the pre-master secret and encrypts it with the TLS server's publicly available RSA key. This generates an encrypted pre-master secret (ePMS), which is then provided to the TLS server. The TLS server has a private decryption key, which is then used to decrypt the encrypted pre-master secret. At this point, both the client and the server have the original pre-master secret and can use it to generate the symmetric key used for actual encrypted and secure data exchange. Decrypting the encrypted pre-master secret is the only time in the TLS connection that the private key is needed. This decryption occurs at a so-called TLS termination point. Where a CDN is used to facilitate delivery of secure content, the TLS termination point will be located in the CDN.
Some CDN customers are not comfortable sharing their private TLS (RSA, DSA, etc.) keys with the CDN service provider. Further, some customers may require an additional caveat that certain data and requests never be decrypted by the CDN at any point in any transaction, and that the data transmitted by the CDN on behalf of the customer is provably and verifiably authentic.
To address this requirement, it is known to augment an overlay network with an RSA proxy “service” that off-loads the decryption of the encrypted pre-master secret (ePMS) to an external server managed by the service provider. Using this service, instead of decrypting the ePMS “locally,” the SSL server proxies (forwards) the ePMS to an RSA proxy server component and receives, in response, the decrypted pre-master secret. In this manner, the decryption key does not need to be stored in association with the SSL server. This approach is described in in U.S. Publication No. 2013/0156189, the disclosure of which is hereby incorporated by reference.
In one embodiment described in that publication, at least one machine in a first network-accessible location includes an RSA proxy server software program, and at least one machine in a second network-accessible location includes an RSA proxy client software program. The RSA proxy server software program and the RSA proxy client software program each include code to establish and maintain a secure (e.g., a mutually-authenticated SSL) connection there-between. The RSA proxy client software typically executes in association with an SSL server component (such as OpenSSL). According to this disclosure, however, SSL decryption keys are not accessible to the RSA proxy client software. Rather, decryption of encrypted pre-master secrets is off-loaded to the RSA proxy server software program. In operation, the RSA proxy client software program receives and forwards to the RSA proxy server software program over the mutually-authenticated SSL connection an encrypted pre-master secret associated with a new SSL handshake request received (at the RSA proxy client) from an end user client program (e.g., an SSL-enabled web browser, a native mobile app, or the like). The RSA proxy server software program decrypts the encrypted pre-master secret using a decryption key that is maintained at the RSA proxy server software program and not otherwise accessible to the RSA proxy client software program. The RSA proxy server software program then returns a decrypted pre-master secret to the RSA proxy client software program over the mutually-authenticated SSL connection. The end user client program and the SSL server component both are then in possession of the pre-master secret (and can use it to generate the symmetric key used for encrypting the connection between them).